chore(deps): update dependency astral-sh/uv to v0.8.0 #21
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.7.17
->0.8.0
Release Notes
astral-sh/uv (astral-sh/uv)
v0.8.0
Compare Source
Since we released uv 0.7.0 in April, we've accumulated various changes that improve correctness and user experience, but could break some workflows. This release contains those changes; many have been marked as breaking out of an abundance of caution. We expect most users to be able to upgrade without making changes.
This release also includes the stabilization of a couple
uv python install
features, which have been available under preview since late last year.Breaking changes
Install Python executables into a directory on the
PATH
(#14626)uv python install
now installs a versioned Python executable (e.g.,python3.13
) into a directory on thePATH
(e.g.,~/.local/bin
) by default. This behavior has been available under the--preview
flag since Oct 2024. This change should not be breaking unless it shadows a Python executable elsewhere on thePATH
.To install unversioned executables, i.e.,
python3
andpython
, use the--default
flag. The--default
flag has also been in preview, but is not stabilized in this release.Note that these executables point to the base Python installation and only include the standard library. That means they will not include dependencies from your current project (use
uv run python
instead) and you cannot install packages into their environment (useuvx --with <package> python
instead).As with tool installation, the target directory respects common variables like
XDG_BIN_HOME
and can be overridden with aUV_PYTHON_BIN_DIR
variable.You can opt out of this behavior with
uv python install --no-bin
orUV_PYTHON_INSTALL_BIN=0
.See the documentation on installing Python executables for more details.
Register Python versions with the Windows registry (#14625)
uv python install
now registers the installed Python version with the Windows Registry as specified by PEP 514. This allows using uv installed Python versions via thepy
launcher. This behavior has been available under the--preview
flag since Jan 2025. This change should not be breaking, as using the uv Python versions withpy
requires explicit opt in.You can opt out of this behavior with
uv python install --no-registry
orUV_PYTHON_INSTALL_REGISTRY=0
.Prompt before removing an existing directory in
uv venv
(#14309)Previously,
uv venv
would remove an existing virtual environment without confirmation. While this is consistent with the behavior of project commands (e.g.,uv sync
), it's surprising to users that are using imperative workflows (i.e.,uv pip
). Now,uv venv
will prompt for confirmation before removing an existing virtual environment. If not in an interactive context, uv will still remove the virtual environment for backwards compatibility. However, this behavior is likely to change in a future release.The behavior for other commands (e.g.,
uv sync
) is unchanged.You can opt out of this behavior by setting
UV_VENV_CLEAR=1
or passing the--clear
flag.Validate that discovered interpreters meet the Python preference (#7934)
uv allows opting out of its managed Python versions with the
--no-managed-python
andpython-preference
options.Previously, uv would not enforce this option for Python interpreters discovered on the
PATH
. For example, if a symlink to a managed Python interpreter was created, uv would allow it to be used even if--no-managed-python
was provided. Now, uv ignores Python interpreters that do not match the Python preference unless they are in an active virtual environment or are explicitly requested, e.g., with--python /path/to/python3.13
.Similarly, uv would previously not invalidate existing project environments if they did not match the Python preference. Now, uv will invalidate and recreate project environments when the Python preference changes.
You can opt out of this behavior by providing the explicit path to the Python interpreter providing
--managed-python
/--no-managed-python
matching the interpreter you want.Install dependencies without build systems when they are
path
sources (#14413)When working on a project, uv uses the presence of a build system to determine if it should be built and installed into the environment. However, when a project is a dependency of another project, it can be surprising for the dependency to be missing from the environment.
Previously, uv would not build and install dependencies with
path
sources unless they declared a build system or settool.uv.package = true
. Now, dependencies withpath
sources are built and installed regardless of the presence of a build system. If a build system is not present, thesetuptools.build_meta:__legacy__
backend will be used (per PEP 517).You can opt out of this behavior by setting
package = false
in the source declaration, e.g.:Or, by setting
tool.uv.package = false
in the dependentpyproject.toml
.See the documentation on virtual dependencies for details.
Install dependencies without build systems when they are workspace members (#14663)
As described above for dependencies with
path
sources, uv previously would not build and install workspace members that did not declare a build system. Now, uv will build and install workspace members that are a dependency of another workspace member regardless of the presence of a build system. The behavior is unchanged for workspace members that are not included in theproject.dependencies
,project.optional-dependencies
, ordependency-groups
tables of another workspace member.You can opt out of this behavior by setting
tool.uv.package = false
in the workspace member'spyproject.toml
.See the documentation on virtual dependencies for details.
Bump
--python-platform linux
tomanylinux_2_28
(#14300)uv allows performing platform-specific resolution for explicit targets and provides short aliases, e.g.,
linux
, for common targets.Previously, the default target for
--python-platform linux
wasmanylinux_2_17
, which is compatible with most Linux distributions from 2014 or newer. We now default tomanylinux_2_28
, which is compatible with most Linux distributions from 2019 or newer. This change follows the lead of other tools, such ascibuildwheel
, which changed their default tomanylinux_2_28
in Mar 2025.This change only affects users requesting a specific target platform. Otherwise, uv detects the
manylinux
target from your local glibc version.You can opt out of this behavior by using
--python-platform x86_64-manylinux_2_17
instead.Remove
uv version
fallback (#14161)In Apr 2025, uv changed the
uv version
command to an interface for viewing and updating the version of the current project. However, when outside a project,uv version
would continue to display uv's version for backwards compatibility. Now, when used outside of a project,uv version
will fail.You cannot opt out of this behavior. Use
uv self version
instead.Require
--global
for removal of the global Python pin (#14169)Previously,
uv python pin --rm
would allow you to remove the global Python pin without opt in. Now, uv requires the--global
flag to remove the global Python pin.You cannot opt out of this behavior. Use the
--global
flag instead.Support conflicting editable settings across groups (#14197)
Previously, uv would always treat a package as editable if any requirement requested it as editable. However, this prevented users from declaring
path
sources that toggled theeditable
setting across dependency groups. Now, uv allows declaring differenteditable
values for conflicting groups. However, if a project includes a path dependency twice, once witheditable = true
and once without any editable annotation, those are now considered conflicting, and uv will exit with an error.You cannot opt out of this behavior. Use consistent
editable
settings or mark groups as conflicting.Make
uv_build
the default build backend inuv init
(#14661)The uv build backend (
uv_build
) was stabilized in uv 0.7.19. Now, it is the default build backend foruv init --package
anduv init --lib
. Previously,hatchling
was the default build backend. A build backend is still not used without opt-in inuv init
, but we expect to change this in a future release.You can opt out of this behavior with
uv init --build-backend hatchling
.Set default
UV_TOOL_BIN_DIR
on Docker images (#13391)Previously,
UV_TOOL_BIN_DIR
was not set in Docker images which meant thatuv tool install
did not install tools into a directory on thePATH
without additional configuration. Now,UV_TOOL_BIN_DIR
is set to/usr/local/bin
in all Docker derived images.When the default image user is overridden (e.g.
USER <UID>
) with a less privileged user, this may causeuv tool install
to fail.You can opt out of this behavior by setting an alternative
UV_TOOL_BIN_DIR
.Update
--check
to return an exit code of 1 (#14167)uv uses an exit code of 1 to indicate a "successful failure" and an exit code of 2 to indicate an "error".
Previously,
uv lock --check
anduv sync --check
would exit with a code of 2 when the lockfile or environment were outdated. Now, uv will exit with a code of 1.You cannot opt out of this behavior.
Use an ephemeral environment for
uv run --with
invocations (#14447)When using
uv run --with
, uv layers the requirements requested using--with
into another virtual environment and caches it. Previously, uv would invoke the Python interpreter in this layered environment. However, this allows poisoning the cached environment and introduces race conditions for concurrent invocations. Now, uv will layer another empty virtual environment on top of the cached environment and invoke the Python interpreter there. This should only cause breakage in cases where the environment is being inspected at runtime.You cannot opt out of this behavior.
Restructure the
uv venv
command output and exit codes (#14546)Previously, uv used
miette
to format theuv venv
output. However, this was inconsistent with most of the uv CLI. Now, the output is a little different and the exit code has switched from 1 to 2 for some error cases.You cannot opt out of this behavior.
Default to
--workspace
when adding subdirectories (#14529)When using
uv add
to add a subdirectory in a workspace, uv now defaults to adding the target as a workspace member.You can opt out of this behavior by providing
--no-workspace
.Add missing validations for disallowed
uv.toml
fields (#14322)uv does not allow some settings in the
uv.toml
. Previously, some settings were silently ignored when present in theuv.toml
. Now, uv will error.You cannot opt out of this behavior. Use
--no-config
or remove the invalid settings.Configuration
v0.7.22
Compare Source
Python
See the GraalPy release notes for more details.
Configuration
UV_COMPILE_BYTECODE_TIMEOUT
environment variable (#14369)cache-control
headers (#14620)UV_LIBC
to override libc selection in multi-libc environment (#14646)Bug fixes
--all-arches
when paired with--only-downloads
(#14629)uv.toml
when provided via direct path (#14653)Documentation
revision
in the lockfile versioning doc (#14634)uv cache clean
prior to--reinstall
(#14659)Preview features
uv python update-shell
(#14627)v0.7.21
Compare Source
Python
fts4
,fts5
,rtree
, andgeopoly
extensions on macOS and LinuxSee the
python-build-standalone
release notesfor more details.
Enhancements
--python-platform
touv sync
(#14320)uv version --bump
(#13578)-w
shorthand for--with
(#14530)UV_HTTP_RETRIES
to customize retry counts (#14544)cache-key
(#13438)..
) in globs incache-key
(#13469)cache-key
performance (#13469)Preview features
uv sync --output-format json
(#13689)Bug fixes
uv tool
if it is incompatible with--python
(#14606)Documentation
include-group
(#14539)setup-python
(#14533)v0.7.20
Compare Source
Python
See the PyPy and
python-build-standalone
release notes for more details.Enhancements
--workspace
flag touv add
(#14496)Bug fixes
uv version
(#14434)uv-extract
to enable retries (#14450)Rust API
NoSolutionError
(#14457)ErrorTree
forNoSolutionError
public (#14444)Documentation
cache-dependency-glob
examples forsetup-uv
(#14493)uv pip sync
suggestion withpyproject.toml
(#14510)setup-uv@v6
(#14490)v0.7.19
Compare Source
The uv build backend is now stable, and considered ready for production use.
The uv build backend is a great choice for pure Python projects. It has reasonable defaults, with the goal of requiring zero configuration for most users, but provides flexible configuration to accommodate most Python project structures. It integrates tightly with uv, to improve messaging and user experience. It validates project metadata and structures, preventing common mistakes. And, finally, it's very fast —
uv sync
on a new project (fromuv init
) is 10-30x faster than with other build backends.To use uv as a build backend in an existing project, add
uv_build
to the[build-system]
section in yourpyproject.toml
:In a future release, it will replace
hatchling
as the default inuv init
. As before, uv will remain compatible with all standards-compliant build backends.Python
See the python-build-standalone release for more details.
Enhancements
--universal
pip compile (#14405)Bug fixes
sys.prefix
in cached environment keys to avoid--with
collisions across projects (#14403)Documentation
v0.7.18
Compare Source
Python
Added arm64 Windows Python 3.11, 3.12, 3.13, and 3.14
These are not downloaded by default, since x86-64 Python has broader ecosystem support on Windows.
However, they can be requested with
cpython-<version>-windows-aarch64
.See the python-build-standalone release for more details.
Enhancements
ManagedPythonDownload::fetch_with_retry
(#14378)Preview features
Bug fixes
python_version
andpython_full_version
(#14271)Documentation
Configuration
📅 Schedule: Branch creation - Between 09:00 AM and 09:59 PM, only on Sunday and Saturday ( * 9-21 * * 0,6 ) in timezone Asia/Tokyo, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.